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Preparar el acabado de 


El número anterior fue 
el segundo dedicado a 
Imagine. Hasta ahora 
hemos estudiado los 
Editores de Formas, 
Detalles, Escenas y 
Proyectos. En 
conjunto lo ya visto es 
suficiente para 
permitir al lector 
acometer proyectos 
de cierta envergadura, 
aunque quedan 
muchas cosas por 
tratar. Por ejemplo, 
¿cómo crear acabados 
planos en los objetos?, 


¿cómo aplicar bitmaps?... 


l acabado es uno de : 


rar imágenes sintéti- E 
cas. Empezaremos E 
viendo cómo crear . 
acabados planos o redondeados. Luego . 
repasaremos el Gestor de Atributos y > 
concluiremos con el tema de la aplicación : 


de bitmaps y la generación de sombras. 


los apartados más : 
importantes al gene- : 


Superficies redondeadas y 
alisadas 

Existen muchos algoritmos de som- 
breado de superficies. Imagine, por de- 
fecto, emplea el sombreado Phong con 
el cual los objetos toman una apariencia 
redondeada ante nuestra vista, a pesar de 
que, realmente, están construidos me- 
diante una malla de caras planas o face- 


¿ tadas. Con este algoritmo se calcula el 


superficies en Imagine 


color adecuado para cada punto de la su- 
perficie atendiendo a la inclinación de 
ésta con respecto a la fuente de luz. Este 
sistema -conocido ya por la mayoría de 
los lectores- permite a los diseñadores 
3d crear objetos de apariencia suavizada 


y realista empleando pocos polígonos. +: 


El sombreado Phong requiere un tiempo 
de cálculo muy superior al llamado flat, 
donde sólo se calcula un único color pa- 
ra todos los puntos de un mismo polígo- 
no, pero también es mucho más real. 
Como ya vimos en el número ante- 
rior, podemos ordenar -¿ferentes tipos 


de sombreado desde la ventana de sub- : 


proyectos. De esta manera todos los 
objetos se verán con una apariencia fa- 
cetada (con “Color shaded”) o bien 
suavizada (con “Scanline” o “Trace”). 
Lo normal es exigir el modo de máxi- 
ma calidad (“Trace”). y 

! Comen' 1100s todo esto porque hay 
un problema que se presentará con fre- 
cuencia en Imagine aunque ordenemos 
la máxima Calidad. Existen objetos cu- 
yas superficies son total o parcialmente 
planas. En estos casos el programa ten- 


Z 18 - 
drá que realizar un sombreado liso o 
suavizado según sea el caso. Algunos - 


programas toman nota de cuando deben 
aplicar el suavizado o no realizando cál- 
culos de ángulos entre polígonos (si el 
ángulo es menor de X, se efectúa el sua- 
vizado). Pues bien, Imagine no es uno 
de ellos. Imagine aplica siempre, por 
defecto, un sombreado suavizado en to- 


das las caras y ello puede hacernos que- 
dar perplejos al observar el acabado fi- 


nal de muchos objetos (como cubos) que E 


sabemos de superficie lisa. No obstante, 

ya hemos visto escenas de Imagine con 

objetos que tienen zonas lisas y zonas re- 
dd - 

dondeadas. Sin ir más lejos, la cabeza de 

Ray (el muñeco pequeño de las gafas de 


talles, seleccionaremos el objeto a tra- 
tar pinchando sobre él (en el modo de 
objetos o en el de grupos). Una vez se- 
leccionado éste cambiaremos al modo 
“Pick Edges”, en el submenú “Mode”. 
Al hacerlo observaremos como los vér- 
tices del objeto quedan recuadrados en 
amarillo. Entonces -desde la ventana 


los números 4 y 5) presenta zonas de las e E una caja de se- 


dos clases. ¿Cómo se hizo esto? 


Veamos; ante todo hay que indicar a-¿ 


Imagine qué partes del objeto deberán 


lección (“Dr ox” en el apartado 
“Pick Method” del submenú “Mode”) 
mientras mantenemos pulsada la tecla 


mostrarse alisadas y cuáles redondeadas. : de Shift (modo múltiple). Los puntos 


En p | er lugar. desde el Editor de De: 


Momento de la selección de 
bordes para el suavizado. 


La ventana de tipos de 
aplicación de bitmaps. 


pa 


A 
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if 
E 


contenidos por la caja queorán selec- 


¿ cionados y podremos añadir nuevos 
OR e 


puntos aesta selección usando nuevas 
cajas. Hecho esto iremos al submenú 
“Fuctions” y pincharemos en “Make”. 
Aparecerá otra ventana de la que des - 
caremos dos opciones; “Make sharp e 
ges” y “Make soft edges”. Si escogemos 
la primera, Los A pre, en- 
tarán una apariencia lisa. Si escogemos 
la segunda, la apariencia será suavizada. 
Normalmente, como por defecto toda la 
A hh. A. 
superficie de los objetos está suavizada, 
' esco gereImos la primera Opción. 
r seleccionando puntos aunque sea 
usando una caja de arrastre puede ser 
engorroso, sobre todo si el objeto es 


Bl complejo, y porello Imagine dispone de 


un segundo método para efectuar estas 
selecciones. En el submenú “Pick/Se- 
lect” hay una opción llamada “Edge Fil- 
ter” (Filtro de aristas). Al pinchar sobre 
ella aparecerá una ventana mediante la 


n la imagen se aprecia en detalle 
la aplicación de un bitmap. 


cual podremos ordenar una selección de 
aristas -que cumpla ciertas condiciones- 
en el objeto o grupo seleccionado. Las 
condiciones más importantes son el án- 
gulo mínimo y máximo entre los que 
debe estar comprendida la arista. Apar- 
te de esto podemos ordenar que la se- 
lección se lleve a cabo sólo entre las 
aristas lisas (“Sharp edges only”) o entre 
las suavizadas (“Soft edges only”). En 
cuanto pulsemos sobre el botón de acep- 
tación, Imagine tomará nota del modo 
en que deberán visualizarse las aristas 
en el proceso de Render. 


El gestor de atributos 

Como ya comentamos en el número 
anterior, para crear los atributos (carac- 
terísticas de superficie) de un objeto o 
modelo seleccionaremos el Editor de 
Detalles (desde el modo de objetos o 
grupos, según sea el caso), y pulsaremos 
sobre “Attributes Requester”, en el sub- 
menú “Functions”. Entonces aparecerá 
la ventana del Gestor de Atributos don- 
de se hallan los botones para dar color, 
transparencia (filter), rugosidad (rough- 
ness) y otras características a los obje- 
tos. En el número anterior ya realizamos 
una breve descripción de la función de 
estos botones y no vamos a entrar ahora 
en más detalles, ya que lo mejor es que 
el lector experimente con ellos. 

Los atributos de superficie así crea- 
dos se guardan automáticamente con 
los objetos, cuando estos se graban. 
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El gestor de las fuentes de luz es 
vital para lograr un buen efecto. 


Aparte de esto Imagine nos permite 
crear librerías de atributos separada- 
mente, empleando los botones “Load” 
y “Save”. (Normalmente guardaremos 
estas librerías en el directorio Attribs). 


Aplicación de bitmaps 

También es en el Gestor de Atributos 
desde donde se realiza la aplicación de 
las texturas. Imagine contempla dos ti- 
pos de ellas. Por un lado están las textu- 
ras tipo bitmap (a las que Imagine llama 
“Brush”) y por otro están las llamadas 
texturas procedurales, las cuales se ge- 
neran siguiendo procedimientos algorít- 
micos. Hoy nos centraremos en la apli- 
cación de bitmaps o mapas de imagen. 

Una vez seleccionado un objeto, y 
ya en la ventana del Gestor de Atribu- 
tos, veremos que el recuadro más gran- 
de dentro de dicha ventana es el que se 
halla bajo el texto “Textures/Brushes”. 
En este recuadro figurará la relación de 
texturas de uno u otro tipo que se va- 
yan a aplicar sobre el objeto (si las 
hay). Bajo el recuadro hay cuatro bo- 
tones relacionados con la aplicación de 
texturas. Por el momento sólo nos in- 
teresa el de aplicación de bitmaps 
(“Add Brsh”). Al pinchar sobre este bo- 
tón aparecerá una nueva ventana que 
nos servirá -buscando entre los direc- 


etalle del gestor de 
transformaciones para los ejes. 


de la textura. Veamos lo que hacen al- 
gunos de sus botones: “Color” es la 
forma de aplicación por defecto y en 
ella el color de cada punto del bitmap 
reemplaza al propio color del objeto. 
“Filter” utiliza la escala de grises del 
bitmap para dar diversos grados de 
transparencia al objeto sobre el que se 
aplica la imagen. (Las áreas negras son 
opacas, las blancas transparentes y las 
grises translúcidas). En cuanto al botón 
“Altitude”, emplea el bitinap para si- 
mular irregularidades (bumpings) en la 
superficie del objeto. Esta opción no pro- 
duce cambios en la geometría sino que 
emplea la información de color del bit- 
map para producir apariencias de abul- 
tamientos o depresiones en el objeto. 
Otros botones importantes son “Flat 
X”. “Wrap X”, “Flat Z” y “Wrap Z”. 
Con ellos especificaremos el tipo de pro- 
yección que efectuará el bitmap sobre el 
objeto, debiendo escoger entre uno u 
otro tipo según la forma del objeto, En 
la portada del número 
ejemplos 9 


al plano 


objeto (en 


torios, si es preciso- para elegir el bit- 
map adecuado. Entonces, si 
un fichero, aparecerá ot 
de la que controlare 


- evitar dis- 


mes visuales. Estas 
visibles como “estira 
1tmap en las zonas del « 


superficie deja de ser perpendicular al 
eje de aplicación. De hecho. si uno de 
los polígonos del objeto queda paralelo 
al eje de aplicación, veremos que cada 
punto del bitmap se estira indefinida- 
mente para cubrir cada punto de la su- 
perficie del mismo. Para comprender 
esto imaginemos un cubo sobre el que 
realizamos una aplicación plana per- 
pendicular a una de sus ca- 
ras. La aplicación resultará 
perfecta en dicha cara y tam- 
bién en la otra cara paralela 
del cubo pero en las otras, en 
cambio, apreciaremos el feo 
efecto de estiramiento. Esto 
se debe a que en la aplicación 
plana del bitmap, cada pixel 
del mismo atraviesa espacial- 
mente al objeto en la direc- 
ción del eje de aplicación y se 
deposita en cada punto de la 
superficie, al entrar en el ob- 
jeto o salir de él. Para evitar 
este efecto hay dos sistemas: 
uno cambiar la orientación del 
eje de aplicación de modo que 
no sea paralelo a nmguna de 
las caras del objeto (lo cual es 
una chapuza) y otro es cam- 
biar el propio objeto. Esto últi- 
mo fue lo que se hizo en la 
terior. donde el bit- 


veces de re- 
lino es el 


En la aplicació: 
¿ bitmap se enroll 
siguiendo la forme 


Modo flat. 


Añadiendo texturas. 


marcaríamos “Flat X” y “Flat Y”. Para 
un cilindro marcaríamos Wrap en un 
eje y Flat en otro y para una esfera mar- 
caríamos Wrap en los dos). 

Otros botón de la ventana con gran 
importancia es “Edit Axes”, con el cual 
podremos controlar directamente la 
aplicación del bitmap. Supongamos que 
hemos elegido el modo flat. Al pulsar 


sobre “Edit Axes” veremos como se vi- 
sualiza un plano (en una de las venta- 
nas) sobre el objeto en ha de efectuarse 
la aplicación. Este plano nos está indi- 
cando la zona donde va a aplicarse el 
bitmap y su orientación y escala con 
respecto al objeto. Podremos alterar es- 
tas características usando los conocidos 
tones de escalación. rotación y des- 
azamiento de la fila inferior de boto- 
ha vez que quedemos contentos 
icación, pulsaremos espacio y 


Acabado suavizado. 


Anadiendo sombras. 


retornaremos a la ventana de aplica- 
ción, donde pulsaremos sobre “Ok”. 
Entonces volveremos a la ventana ante- 
rior donde veremos como el nombre del 
bitmap se ha incluido en el recuadro 
“Textures/Brushes”. 

Para eliminar este bitmap o cambiar 
la aplicación del mismo sobre el objeto 
pincharemos sobre “Info”, lo cual nos 
hará entrar nuevamente en la 
ventana de aplicación desde 
la cual podremos llevar a ca- 
bo la modificación o bien 
eliminar la aplicación pin- 
chando en el botón “Drop”. 


Sombras 

Para que los objetos arrojen 
sombras habremos de activar 
el flag “Cast Shadows” en la 
ventana “Light Source Info”. 
Para acceder a esta ventana 
tendremos que ir al Editor de 
Acciones, cuyo funciona- 
miento no vamos, por ahora, 
a explicar. Para nuestros fi- 
nes bastara con saber que es 
aquí donde podemos cam- 
biar las propiedades de la 
fuente de luz. Al entrar en el 
Editor veremos una pantalla 
de trabajo donde cada objeto 


tiene un nombre situado en alguno de 


los recuadros de la izquierda. Buscare- 


mos el nombre de la fuente de luz (nor- 
malmente “Lightsource”) y pinchare- 
mos primero en el botón “Info”, 
situado en la esquina inferior 1zquier- 
da, y luego en uno de los puntos de co- 


lor del cuadro situado a la derecha del 
nombre de la fuente. Entonces apare- 
cerá la ventana “Light Source Info”, 
donde marcaremos el recuadro antes 
mencionado. 
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La atmósfera en POV 3 


oy 


nte todo conviene ' 
empezar repitiendo En algunas ocasiones hemos z 
la advertencia del — 

Povieam: la senten- álgunos de los efectos a de 


cia “Atmosphere” 


es aún experimental POV, como la niebla, los halos y 8 


y existe una alta probabilidad de que — 
sea modificada en una futura versión as celestes. Pero, hasta in 


de POV, de modo que se pierda la com- 
patibilidad con la instrucción actual. hecho caso omi 
De todos modos, teniendo en cuenta el y> 
interés intrínseco de esta sentencia, he- sentencia ex pe 
mos decidido trastear con ella. 
precisamente * 
El modelo atmosférico de POV 


Según el manual de POV: “la senten- diaremos esta omisión, 
cia atmosphere se emplea para reflejar 
la interacción de la luz con las partícu- 
las del aire”. Con Atmosphere, las emi- 
siones de luz serán visibles y los objetos 
arrojarán sombras sobre la niebla o el 
polvo suspendido de la atmósfera. Esto 
es un paso adelante con respecto a la 
sentencia Fog, la cual no es sino una 
aproximación bastante simple al fenó- 
meno de la niebla (recordemos que Fog 
no interactúa con la luz). Por supuesto, 
Atmosphere es también, como cualquier 
otro intento de simular los fenómenos 
del mundo real en un ordenador, una 
aproximación. Pero produce resultados 
más reales que Fog gracias al muestreo 
de volúmenes espaciales que realiza su 
algoritmo para calcular la interacción 
entre la luz y las partículas atmosféricas. 

El actual modelo atmosférico gene- 
rado con Atmosphere asume una den- 


El cuarto sin atmosfera y 
la atmosfera con un valor 
bajo de muestreo 


sidad constante de partículas en el aire, 
exceptuando el volumen espacial de los 
objetos sólidos. Si queremos crear nu- 
bes, humo u otras distribuciones irregu- 
lares de partículas deberemos recurrir a 
los halos. La sintaxis de la sentencia es: 
atmosphere ( 

type NUMERO_DEL TIPO 

distance DISTANCIA 

[ scattering SCATTERING ] 

[ eccentricity ECCENTRICITY ] 

[ samples SAMPLES ] 

[ jitter JITTER ] 

[aa_threshold AA THRESHOLD ] 

[aa_level AA_LEVEL | 

[ colour <COLOUR>] 

] 

La palabra “Type” se usa para indicar 
el tipo de modelo de dispersión lumino- 
sa que va a emplearse (o sea, cómo van 
a dispersar la luz las partículas de la at- 
mósfera). El modelo más sencillo y rá- 
pido es el isotrópico (el 1), en el cual la 
cantidad de luz dispersada no depende, 
como en los otros modelos, del ángulo 
entre la dirección de visión y el rayo de 
luz. El modelo isotrópico es el que he- 
mos empleado en todos los ejemplos. 

La siguiente palabra, “Distance”, es 
usada por POV para averiguar la densi- 
dad deseada de las partículas de la at- 
mósfera. Como antes se ha dicho, esta 
densidad será constante para toda la at- 
mósfera. “Distance” funciona aquí igual 
que para la niebla constante en la que, 
recordemos, cuando la distancia de un 
objeto iguala a la del valor dado a ““Dis- 


tance”, el color del objeto estará com- 


puesto por un 64% de color propio y 
por un 36% del color de la niebla. 

La palabra “Scattering” se usa para 
cambiar la cantidad de luz que es dis- 
persada por la atmósfera. De esta mane- 
ra controlaremos el brillo de la misma. 
Los valores pequeños disminuyen el bri- 
llo y los valores altos lo incrementan. La 
luz que no es dispersada, es absorbida. 

Con la palabra “Color” (o “Colour”) 


¿ podremos especificar un color para la 


atmósfera. El color puesto por defecto 
es el negro. En cuanto a la cantidad de 
luz que es filtrada por el color de la at- 
mósfera, depende del valor dado en el 
parámetro filtro. Por ejemplo con “rgbf 
<1.0,0,0.40>“, el 40% de la luz será fil- 
trada hacia el color de la atmósfera. Así 
pues, un valor de .10 significa un tono 
muy tenue de rojo y un valor de .70 1m- 
plica una atmósfera “marciana”. Tam- 
bién podernos emplear “Transmittance” 


3 envezde “filter” (o sea; “rgbt”). Trans- 


mittance, que funciona aquí igual que 
en Fog. se emplea para especificar el 
mínimo de translucidez de la atmósfera. 

El algoritmo empleado por “Atmosp- 
here” funciona realizando muestreos 
del volumen espacial a lo largo del rayo 
de visión. En cada punto muestreado se 
tomará nota de si dicho punto cae den- 
tro de un rayo de luz o no. Si un punto 
muestreado cae dentro de una zona ¡lu- 
minada, la cantidad de luz dispersada 
en la dirección del observador será de- 
terminada y sumada a la intensidad to- 


La atmosfera con 
supermuestreo. 


tal. El número de estos muestreos será 
determinado por la palabra “samples”, 
que indicará el número de muestreos 
que se efectuarán para cada intervalo 
en el rayo de visión. La longitud de cada 
intervalo será o bien la distancia dada 
por “Distance” o bien la longitud hasta 
una parte iluminada por un rayo de luz. 
En cualquier caso lo que debemos re- 
cordar es que a mayor número de mues- 
treos, más reales serán los resultados. 

Otro punto a tener en cuenta es que, 
como el resultado final depende de una 
serie de testeos a lo largo de un volumen 
espacial, será conveniente realizar un 
antialias en los resultados, Por supuesto, 
podemos limitarnos a dar un valor lo su- 
ficientemente alto a “samples”. pero es- 
to sería parecido a generar siempre imá- 
genes a resoluciones muy altas (en 
cuanto a coste de tiempo). Otra solución 
viene dada por las palabras “Jitter”, 
“aa_level” y “aa_threshold”. 

Usando jitter, el punto espacial donde 
va a efectuarse el muestreo es desplaza- 
do una pequeña distancia aleatoria a lo 
largo de la dirección del rayo del obser- 
vador, lo cual ayuda a reducir el proble- 
ma del “escalonamiento”. Un buen va- 
lor para jitter es 0.5. Valores más altos 
pueden producir un exceso de “ruido” 
visual en los resultados. 

Otra posibilidad para evitar este pro- 
blema es efectuar un “super-muestreo” 
(super-sampling). Esta técnica realiza 
muestreos adicionales en las zonas 
donde las intensidades entre dos puntos 


8 Rendermania 


Taller Virtual 


La atmósfera 
con color negro. 


Mmuestreados son muy diferentes. En ese 
caso se realizarán más muestreos de for- 
ma recursiva hasta que se alcance el ni- 
vel de recursión indicado o hasta que las 
diferencias de intensidades entre los 
puntos muestreados queden dentro de lo 
tolerable. La palabra “aa_level” indica el 
nivel máximo de recursión y la palabra 
“aa_threshold”. la diferencia máxima 
permitida entre la intensidad de dos mues- 
treos (a fin de dar por acabado el proceso). 


Los ejemplos de POV 

En el directorio docsdemo de POV 
se incluyen varios ficheros de ejemplo 
cuyo nombre empieza por atmos para 
ilustrar el uso de “atmosphere”. En to- 
dos ellos (salvo en el último) se mues- 
tra una habitación iluminada con una 
fuente puntual. La habitación consta de 
una ventana por la que entra la luz de 
una fuente spotlight, que ilumina el 
suelo. En el primer ejemplo, atmos!. 
no hay atmósfera de ninguna clase. En 
el siguiente caso, atmos2, se añade la 
atmósfera pero el resultado, un efecto 
de escalonamiento luminoso, no es 
muy bueno. En el tercer ejemplo hay 
algunas mejoras que dan un resultado 
más vistoso. La primera mejora consis- 
te en un valor de muestreo bastante ma- 
yor. Además. se añade un porcentaje de 
“jitter” y se añade el supersampleado. 


Cuestiones a tener en cuenta 
Cuando usemos “Atmosphere” debe- 
mos asegurarnos de que todos los objetos 


La atmósfera con 
un filtro de rojo. 


que deban tener atmósfera sean declara- 
dos como huecos con hollow. Esto tendre- 
mos que hacerlo incluso con la primitiva 
“plane”, tal como sucedía con los halos. 

De igual manera, “Atmosphere” no 
funcionará si la cámara no está coloca- 
da en un objeto hollow. 

Cuando, después de realizar una se- 
rie de pruebas, deseemos lanzar una 
imagen definitiva a mayor resolución, 
tendremos que aumentar el número de 
muestreos. De lo contrario apreciaremos 
efectos de escalonamiento que no resul- 
taban visibles a resoluciones inferiores. 

Por defecto, las fuentes de luz interac- 
túan siempre con la atmósfera. Si en al- 
gún caso deseamos evitar esto bastará 
con añadir la palabra “atmosphere off” 
en la declaración de la fuente. Esto es lo 
que hemos hecho con la fuente puntual 
azul de la escena de la malla tridimen- 
sional. La otra fuente de luz es una “Spo- 
tlight” corriente con “Atmospheric_atte- 
nuation on” (en la escena de la malla 3d 
se ha sustituido la antigua niebla que se 
puso en el número 2, por una sentencia 
“atmosphere”; este experimento, no de- 
masiado logrado, fue el primero realiza- 
do por el autor con esta sentencia). 

Normalmente los rayos de una fuen- 
te no se debilitan -en POV- al atravesar 
la niebla o la atmósfera. Si deseamos 
cambiar este comportamiento usaremos 
la palabra “Atmospheric attenuation” 
dentro de la declaración de la fuente. 
Este atenuamiento sólo funcionará si la 
escena tiene atmósfera o niebla. 
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Programación de un 
desastre a escala global 
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Quienes dominan la filosofía de POV 
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sentencias “de prog amación”- permiten 
la creación de escenas que resultarían 
sumamente difíciles co 
programas. Esto es algo que ya hemos 
comprobado en diversos números de ld 
Rendermanía, pero aún no puede decirse 
que hayamos explorado todas las A 
posibilidades de la “pov-programación” 
como herramienta de diseño infográfico. 


2 usuario en 


s la recursión? ¿Cómo 
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n edificio en ruinas 

O -peor aún- una ciu- 

dad en ruinas viene 

a ser el típico ejem- 

plo de proyecto que 

resulta muy fácil de 
realizar con POV pero bastante difícil de 
acometer con otros programas como 
Imagine o 3D Studio. La razón es, por 
supuesto. que en el diseño de un proyec- 
to de este tipo intervienen factores repe- 
titivos O patrones que son fácilmente re- 
presentables si disponemos de un 
lenguaje escénico (como el de POV). 
Con un lenguaje podremos crear bucles, 
cambios en el diseño básico dependien- 
do de ciertas condiciones, y otras cosas. 
Hay que tener en cuenta que un edificio 
corriente (en ruinas o no) equivale a un 
montón de objetos simples que se repi- 
ten una y otra vez tales como vigas, 
plantas, columnas, etc. Con POV pode- 
mos emplar las sentencias de bucles pa- 
ra, con unas cuantas líneas. crear un edi- 
ficio de este tipo. También podemos 
emplear las sentencias de azar para in- 
troducir pequeñas irregularidades en el 
tamaño o en la composición de los mo- 
delos y -por último- podemos emplear 
nuevamente las sentencias iterativas pa- 


ra componer una matriz de edificios, 
creando así una ciudad. Con POV todo 
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esto puede ser posible con un corto fi- 
chero de texto. ¿Os imagináis el trabajo 
que implicaría el montaje de cada uno 
de estos elementos “a mano” con un 
modelador de ventanas? 


Lo que pretendemos 

La idea de la que nació el proyecto de 
la ciudad arrasada partió de las barraba- 
sadas a las que sometió Katsuhiro Oto- 
mo a Neo-Tokio en su ultrafamoso 
manga Akira. En dicho manga esta des- 
dichada ciudad es primero destrozada 
por una bomba nuclear, luego, ya re- 
construida, es vuelta a destrozar por 
Akira, después es sometida a la guerra 
civil psiquica, más tarde es bombardea- 
da por los americanos y, por último, es 
vuelta a “ultradestrozar” por Akira. Ni 
que decir tiene que los fondos de las vi- 


ñetas de esta obra están 
llenas de edificios destro- 
zados. El resultado gráfi- 
co es espectacular pero, 
sin embargo, una de las 
cosas que más saltarán a 
la vista de cualquier pov- 
adepto -sobre todo en las 
últimas páginas- es que 
casi todo el efecto se lo- 
gra mezclando edificios 
que -aunque muy detalla- 
dos a veces- son muy fáciles de repro- 
ducir con POV. Esto se debe a que los 
edificios futuristas dibujados por Oto- 
mo están creados con muy pocos ele- 
mentos diferentes. Estos elementos, en 
cada edificio, están desalineados, rotos 
y retorcidos pero son, en definitiva, de 
muy pocos clases distintas y de formas 
muy sencillas. Para comprobar esto 
crearemos primero un edificio sencillo 
y luego lo destrozaremos. 


Aquí no hay calles (ni playa) 
Bueno, realmente si había algo en 
Akira que era de muy difícil representa- 
ción; las montañas de escombros que 
llenaban las calles. Ciertamente habría- 
mos podido representar estos escombros 
de varias formas distintas, pero la única 
manera convincente hubiera sido apilar 


cientos de pequeños objetos de formas 


variadas. Además tendríamos que haber 
representando las irregularidades de las 
calles; el suelo levantado, las aceras, las 
farolas, etc. Y además, habría que haber 
preparado también las entradas de los 
edificios, lo cual hubiera sido, sin duda, 
la parte mas difícil del diseño. 

Aquí hemos solucionado el proble- 
ma a la manera gordiana clásica: supri- 
miéndolo. Esto se ha hecho cambian- 
do el tipo de desastre que en nuestras 
páginas ha pasado a ser un recalenta- 
miento de la temperatura mundial glo- 
bal, lo cual ha producido el deshielo de 
los casquetes polares acompañado de 
la consiguiente subida del nivel del 
mar. De esta manera, al suponerse que 
los edificios están parcialmente sumer- 
gidos, nos hemos ahorrado todo los 
problemas antes descritos. 


Año 2034 

La verdad es que puede decirse que 
nuestros edificios pertenecen es. épo 
Cas diferentes. En la primera la catás:ro- 
fe es aún muy reciente y los edific:os es- 
tán prácticamente intactos. en la 
segunda el tiempo ha pasado y los edifi= 
cios muestran señales de cgbsión, y en 
la tercera ha pasado añu más tiempo 
—quizá siglos— y los edificios están a 
punto de derrumbarse. Para representar 
la primera época tisaremos el fichero 
editi0.pvm del Gue eliminaremos las 


sentencias rand. Además sustituiremos 
las texturas bitmap en el fichero pov por 
colores planos. Para la segunda epoca 


emplearemos el mismo fichero .pvm, 
sin cambios, y sin sustituir las texturas 
en el fichero pov. Finalmente, para la 
tercera época. emplearemos el archivo 
edifil.pvm. (A partir de ahora citaremos 
un año para referirnos a los edificios de 
cada época; 2034 para los edificios de la 
primera época, 2056 para los de la se- 
gunda y 2110 para los de la tercera). 

Para los edificios de cada epoca el 
modo de construcción es casi el mismo. 
Cada edificio está compuesto por 4 fa- 
Chadas, los techos de cada piso, el tejado 
y su barandilla y las columnas laterales. 
Cada fachada. a su vez, está compuesta 
por tres elementos: los bloques horizon- 
tales, los verticales y los cristales (si los 
hay) de las ventanas. Todos nuestros 
edificios se construyen empleando el 
mismo algoritmo de construcción, en el 
cual se suministra al fichero “macro” el 
número de pisos isos) y el númena de 
ventanas (nventanas). Otros parámetros 
servirán para determinar la forma del 
ediiicio. Con las variables “npisos” y 
pventanas” el algóritmo del fichero 
vm empleado constituye 4 fachadas cb- 
yo tamaño puede deiénminarse así 

ancho=nventanas 4 

alto=npisos*53 

suponiéndose que cada unidad equi- 
vale a un metro. 


Examinando los ficheros el lector no- 


tará que en cada edificio las fachadas 
podrían haberse construido empleando 
unas pocas vigas verticales cuya altura 
fuese igual a npisos*5. También podría- 
mos haber procedido de manera similar 
con las vigas horizontales. Pero, en lu- 
gar de esto, hemos empleado muchas 
vigas más pequeñas de tal forma que 
tendremos que, para cada fachada 
numero_de_vigas_verticales= npisos*nventanas 
siendo cada viga vertical de 5 metros 
de altura. 

Y lo propio sucede con las vigas ho- 
rizontales. Quizá el lector se sienta algo 
perplejo al considerar que podríamos 
haber logrado el mismo resultado grá- 
fico con muchas menos vigas de mayor 
longitud. Esto es cierto pero solamente 
para los edificios del 2034. Para los 
posteriores nos resultará más conve- 
niente el formato empleado. 


Año 2056 

Los edificios del 2034 están prácti- 
camente nuevos y, resultan decepcio- 
nantes puesto que sun excesivamente 
sencillos. Colocados Bhyegran número a 
cierta distancia de la cámara podrían, 
quizá, cumplir su papel peroypay que 
recordar que r.Mienen puertas, hhudor- 
nos de ninguna tlase y además resu!- 
tan excesivamente parecidos y unifor- 
mes entre sí. 

Los del año 2056, en cambio. ofre- 
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cen un resultado gráfico más atractivo 
precisamente porque están más trabaja- 
dos por el tiempo. Para empezar hemos 
aplicado una textura creada con Photos- 
hop en la que —aparte de ciertas rugosi- 
dades debidas a la erosión— se aprecian 
grietas y roturas varias. El siguiente pa- 
so ha sido aplicar un efecto aleatorio 
comprendido entre O y 12 grados a la 
orientación de cada una de las piezas- 
viga que componen las fachadas. Tam- 
bién hemos hecho que el sentido del gi- 


ro para cada pieza dependa de un factor E 


aleatorio. Esto se logra con las líneas 

Hideclare a=rand(semilla) 

Hif (a<.SO) fideclare a=1 

Htelse tHideclare a=-1 

Htend 

Como recordaréis, la función rand de 
POV devuelve un resultado flotante ale- 
atorio entre O y 1 empleando la semilla 
inicializada con la función seed. Por tan- 


to las probabilidades de obtener un valor E 


E para la variable “a” son del 50%. En 


6,79 


las líneas siguientes empleamos “a” pa- 


ra determinar el sentido del giro en cada : 


pieza vertical así, la línea siguiente 
object(viga_v rotate x*(rand(semilla)* 12)*a) 


crea una viga vertical a la se que rota : 


una cantidad aleatoria de grados (com- 
prendida entre O y 12) en el eje X. El 
giro se efectuará en un sentido o en 
otro dependiendo del valor de “a”. Este 


truco también se emplea con las piezas : 


horizontales y con las columnas latera- 
les del edificio cuando las hay. 


Año 2110 


Aunque el listado es casi el mismo, 
los edificios del 2056 parecen más con- 
seguidos que los del 2034. Sin embargo 
aún no podemos ejecutar la danza de la 
victoria ya que el acabado “catastrófi- 
co” del 2056 aún no es perfecto. Como 
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sabemos, en los edificios lo suficiente- 
mente “arruinados” suele haber aguje- 
ros y roturas que se aprecian en zonas 
aleatorias de los mismos. Para conse- 
guirlas había que realizar restas espa- 
ciales (differences) entre el vohumen de 
cada edificio y otros objetos. Ahora 
bien, ¿qué tipo de objetos se pueden 
emplear para efectuar dichas restas? La 
primera idea fue usar una unión de es- 


feras escaladas y situadas aleatoriamer 
te dentro de un espacio cúbico. Quizá 
esto habría funcionado pero. temiendo 
que los recortes espaciales dejarán a los 
edificios con la apariencia de quesos de 
gruyere, se optó finalmente por emplear 
Heightfields. Estos objetos —como re- 
cordará el lector— se usan normalmente 
para crear mallas de apariencia monta- 


ñosa y su aspecto irregular resultaba. | 
pues, ideal para los recortes espaciales 
que se deseaban. 

Así pues se creó una union de 
heightfields para efectuar las restas en 
cada edificio. Cada heightfiel fue pri- 
mero rotado para que los picos de 


montañas apunios ad 


an baja como 


También se ha prescindido de la pa 
bra smooth, ya que el suavizado del ob- 
jJeto de recorte no era necesario y evi- 
tándolo podíamos ahorrar un poco más 
de memoria. 


Finalmente —y para ahondar aún más 
en el aspecto ruinoso de nuestros edifi- 
cios- podemos incluir un leve valor alea- 
torio de inclinación a cada edificio. 


¿Macros o funciones? 

En:cuanto q lu. estructura delos fi- 
cheros.de generación, en esta ocasión 
hemos empleado lo que algunos usua- 
rios de: POV han dado en llamar “fun- 
ciones de usuario de POV”. ¿Qué ocu- 
rre con estas “funciones”? Algunos 
usuarios —entre ellos vuestro:seguro 
servidor= afirmaban que POV no las 
implementa mientras que utros asegu- 
raban fervientemente que sí. Además 
en el número anterior, en el foro del 
lector, el grupo Mithrandor envió una 
carta tratando este particular. Después 
de leer dicha carta el autor de estas lí- 
neas se inclino a dar la razón a los 
“funcionalistas” si bien, una vez pasa- 
do el entusiasmo inicial, vuestro seguro 
servidor ha retomado nuevamente su 
Opinión inicial, o sea, ¡no existen las 
funciones de usuario de POV! 

¿Cómo debe entenderse esto? Cuan- 
do se habla de funciones de usuario de 
POV se está dando a entender que di- 
chas funciones son similares en cuanto 
asu funcionamiento a las funciones de 
C. (De hecho el autor de estas líneas re- 
cuerda vagamente haber leído algún 
fag al respecto hace ya algún tiempo). 
Las funciones de C,. como saben los 
programadores, son bloques de código 
que, generalmente, realizan tareas con- 
£retas cuyos objetivos puede variar de- 
pendiendo de los parámetros que se les 
pasen. Una vez compilado.el progra- 
ma, el código correspondiente a una 
función dada solamente se almacena 
una vez en memoria debiendo encar- 
garse el programa de efectuar una lla- 


mada a la posición adecuada para que 
la función lleve a cabo su labor. Esta 
última condición es precisamente la 
que no cumplen tas funciones de usua- 
rio de POV. 

Veamos lo que sucede con la “fun- 
ción de usuario” incluida en edifi!.pvm: 


1) POV está efectuando el “parsing” 
(compilación) de alguno de los fiche- 
ros .pov que llaman a edifit.pvm. La 
“función” de edifil .pvm creará un edi- 
ficio cuyas dimensiones y forma de- 
penderán de los valores que se pasen en 
Los “parametros” nventanas, npisos, la- 
teral, window, vigav y vigah. Después 
de dar un valor a cada parámetro preci- 
so, la siguiente línea del fichero .pov 
será Htinclude “edifil.pvm”. 

2) Cuando el parser (la parte de POV 


encargada del parsing, o sea de conver- 
tir en “código 3d” los ficheros escéni- 
cos) llega a la línea del include, lo que 
sucede es, sencillamente, que se actúa 
como si todo el fichero edif11.pvm es- 
tuviera escrito —a partir del include— en 
el archivo .pov en curso. POV “inclu- 
ye” su texto línea a línea en el archivo 
.-pov y cuando termina de parsear las 
líneas de edifil.pvm continúa con las 
del archivo .pov inicial. Cuando, más 
adelante, en el mismo archivo, POV 
encuentre otra línea Hinclude “edi- 
fil.pvm”, el proceso se.repctirá. aun- 
que puede que los resultados visuales 
sean muy diferentes ya que, presunta- 
mente, los parámetros para esta llama- 
da a la función serán diferentes a los 
de la primera llamada. 

Exteriormente podrá parecernos que 
el funcionamiento de esta pov-función 
es similar al de las funciones de C pero, 
internamente, lo que sucede se parece 
mucho más al proceso de expansión de 
una Macro de, por ejemplo, lenguaje 
ensamblador. (Por eso aquí empleamos 
la extensión pvm; pov-macro). Sin em- 
bargo, y precisiones aparte, el truco es 
de una granutilidad ya que podremos 
ahorrarnos la escritura de muchas Hí- 
neas y estructuraremos mejor nuestras 
escenas: El lector hallará ejemplos de 
todo esto en edificio.pov, ciudad.pov y 
portada.pov. 


Los distintos tipos básicos 
de edificios 

Las definiciones de los bloques bási- 
cos de los edificios se hallan en los fi- 
cheros pov, con lo que basta con cam- 
biar dichos bloques para crear nuevos 
tipos. Los tipos que hemos empleado 
se hallan definidos dentro del switch, 
en ciudad.pov. 
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as 


La Portada 


Escenas desastrosas 


No hay duda de que, a pesar de que el 


fantasma de la guerra nuclear está un tanto 


difuminado hoy día, el genero catastrofista goza 


de buena salud. Multitud de autores se afanan 


en plasmar catástrofes de todo tipo, ya sea en 


letra impresa, en viñetas o en imágenes. Hoy 


nos sumaremos a esta ¿corriente? proponiendo 


una catástrofe mundial a escala global (y virtual 


afortunadamente), en la que el recalentamiento 


del planeta ha conducido al deshielo de las masas 


polares. ¿El resultado? Ciudades sumergidas y 


en ruinas como la que podéis ver en la portada. 


Os pormenores de la E 
construcción de los E 
edificios de la porta- 
da ya han sido des- ¿ 
critos en “Progra- E 
mación 3D”. Ahora : 
explicaremos el proceso por el cual la E 
: tidad, que parece excesiva ante la E 


portada quedó tal como podéis verla. 


Problemas en la creación 
del area catastrófica 


Algunas de las ideas citadas en “Pro- : 
gramación 3d” no han sido llevadas a : 
cabo en nuestra portada. De hecho los : 
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edificios empleados en ella no son los E 
más desastrosos (y resultones) de que ] 
disponemos, sino otros más sencillos. ¿ 
Los problemas han sido los de siempre: E 
tiempo y, sobre todo, memoria. La es- ¿ 
cena de portada, por ejemplo, ha re- : 
querido unos 44 Megabytes. Esta can- ¿ 


: sencillez de los modelos, se explica por: 
E la existencia de los cientos de peque- : 
a ños objetos simples que componen ca- E 
da edificio. Estos objetos simples, ro- . 
tados levemente en distintos ejes, : 
producen (o deberían producir) una : 


buena impresión de destrozo y de com- 


plejidad en cada modelo. En cuanto a 
la construcción de la ciudad, se ha em- 
pleado un bucle doble muy similar al 
que en su día se usó en las ciudades 
medievales (ya que el principio es el 


mismo). Este bucle, en la portada, sir- cristal y una media de 10*6 ventanas 
vió para generar 6*6 edificios. Estos 


“ruinosos” modelos, salvo por los suelos 


por fachada—, hay una media de medio 
millar de piezas simples por edificio. 
Por otro lado, si en vez de los mode- 


de cada piso, carecen de partes internas 
los empleados hubiéramos usado los 
edificios del 21 10. la situación aún hu- 


pero aún así —y asumiendo 2 vigas por 


cada ventana, la posible adición de un 


biera empeorado más, ya que cada edi- 
ficio de esta época sufre recortes por 
parte de 5 heightfields.para aumentar la 
impresión de vejez. Además de esto, 
como siempre, mayor complejidad sig- 
nifica mayor lentitud en la generación 
de las pruebas. Quizá una posible solu- 
ción hubiera estado en el empleo de 
uno u otro tipo de edificio atendiendo a 
la distancia de estos con la cámara. 

Otro problema de la portada es la poca 
variación entre los distintos tipos de edi- 
ficios. En la pov-macro switched.pvm só- 
lo se definen 5 variaciones entre todos los 
casos posibles pero lo peor es que los dis- 
tintos elementos simples usados para 
crear estas variaciones son demasiado pa- 
recidos entre sí. (Por esta razón no nos 
hemos molestado en añadir más casos). 
Las macros edifi0 y edifil emplean ob- 
jetos declarados fuera (o sea en el fichero 
«pov de llamada) para preparar el monta- 
je de cada edificio. Esto resulta cómodo 
pero poco ágil. Por otro lado quizá esto 
no sea necesariamente malo; el hacer ti- 
pos de edificios diferenciados entre sí 
probablemente daría como resultado que 
nos fijáramos aún más en las repeticio- 
nes, a menos, claro está, que escribiéra- 
mos una librería de edificios extensa. 
Esto no era lo que hoy se pretendía ¡ya 
que de todas formas los edificios iban a 
acabar como un montón de ruinas! 

Un último punto a tener en cuenta es 
el hecho de que estamos usando una 
única semilla para decidir los factores 
aleatorios de todo: el número de venta- 
nas y pisos, la forma de los edificios..., 
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etc, Esto significa que no peramos hallar algún buen 


podremos predecir el resul- conversor de objs de Ima- 
tado visual final salvo de 


una manera muy aproxi- 


gine en un futuro. 


POV 3.01 


Finalmente hay que rese- 


mada. Claro que. por otro 
lado esto también tiene su 
atractivo, ya que bastará ñar que todos los renders 
con cambiar el valor del pa- del presente número —sal- 
rámetro de seed para obte- vo las páginas dedicadas a 
Imagine— fueron hechos 

En portada.pov hemos con POV 3.01, una actuali- 
utilizado el sistema del do- : , zación que corrige varios 
ble bucle con factores aleatorios para E emplear m: modelos decdificios del 2110a E bugs de la anterior y que podéis encon- 
crear una malla de edificios. Después ] los que : se se inclinarán sobre: su eje segú trar en la siguiente dirección de internet: 
hemos colocado “a mano” un edificio unfactor aleatorio y también, se acanl 
de 22 pisos de altura y en él al monstru hideade reescribir los sedificios ds 


Puede suceder que un valor dado para : do ue - pudieranex ende! 


Pm 


ner una ciudad distinta. 


o, http://Www.povray.org 

ems esta nueva versión permite 
xtraer un doctorial en formato html y 

otro en modo texto, por si no nos hace 


acia el modo de ayuda normal. Pode- 
Ithero html y meterlo 


seed dé como resultado unos edificios 


excepcionalmente altos en las filas más 


cercanas, con lo que no verem oluir- os extraer 


lo que diera una idea adecuad E ea ur subdir ] llamado html! con 
tamaño de los edificios. La elección - Y 1siguient Mínca; 
ba muy clara dado que en el último Y Phe2hur I -ipovhclp. phe -ohtmK 


- número de Rendermania se incluyo un 


más allá de ellos. También pued 


rrir que obtengamos una Ci ida d adecua- de ' 
da salvo por un detalle que no pod: 
cambiar ya que nuestro único 

sobre el resultado será pedirle al progr obot. Ahora bien, ¿cómo exportarlo a 


 POV? Bien, en Rendermanía número 1 


y i y -ppov 
' én SO) extraer el fichero 
cii ON; An 
ad -oVhcippho 

HUEVO 1 mary! ha cambiado algu- 
40 Moe ONES y 


ratamos el tema de la exportación de 
odelos para POV. Todo cuanto se dijo Y 


en 


La portada 


Como antes se dijo. 


quel artículo acerca la orientación de pr 


el mar para no tener que 


etc. Otra posible solución hubiera sido e AN RO NOS ser á de m do me 

semienterrar la ciudad entre las dunas ponemos de alg ne ia gua : 

un desierto. Esto, sin embargo, haría que 3 “traduzca” el formato o de l ORTANTE 

fuese bastante mas difícil predecir lawi= ¿ Elauto de estas va ara hacer vuestras propias pruebas: 

sibilidad de cada edificio concreto. esta herramien 'opiad los ficheros .pov, .inc y .pvm a un 
Aparte de esto se barajó la posibili- E truo creado a ¡ne rabado en 3 mismo directorio. Meted ahí también la 


dad de poner la cámara a ras del agua : formato D) o. esto las alternati- textura texed.tga (la textura de las pare- 


para enfocar algún edificio cercano en : vas son algo más amplias ya que existen des) y. si vais a emplear edifi pvm, meted 


el que se viera a nuestro monstruo prac- : muchos programas que “entienden” este también los ficheros image o cread los 
ticando alpinismo, pero esta idea fue de- . formato; Wevt2pov puede, por ejemplo, vuestros propios. También puede resultar 
sechada ya que hubiera sido muy difícil : leer DXF y grabar ficheros pov. Y tam- necesario realizar ligeros cambios en los 
ofrecer así un panorama global de la : bién podemos grabar en formato 3ds y ] ficheros .pvm dependiendo de cual sea el 
ciudad. También estaba previsto (¡Ay!) E convertir luego a pov con 3ds2pov. Es- E fichero .pov tratado. 
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Voss 


El Foro del Lector 


Nota importante. Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
figura en la segunda página de Pemanía, o vía e-mail a rendermania.pomaniaO hobbypress.es 


Piezas para juegos y 
batallas virtuales 


Nuestro foro de hoy 
resultará especialmente 
interesante a todos los 
rendermaniacos por su 
diversidad. Incluye, entre 
otras cosas, una librería de 
piezas para crear juguetes 
Tente de modo virtual, 


unas cabezas 


extraterrestres modeladas En el número 4 de Rendermanía publicamos el carro de vapor creado por 
Óscar Alvarez Díaz. Este vistosa vehículo inspirado en el mundo de War- 

con Metaballs , M ás hammer fue el único modelo superviviente del disco enviado por su creador. 
Escarmentado por este desastre informático, Oscar ha vuelto a enviarnos su 

pov-p lezas virtuales para la trabajo adjuntando esta vez copias de seguridad ¡lo cual ha sido una suerte ya 
que uno de los discos volvió a fallar! (Rendermantacos, tomad nota: Enviad 

anunciada batalla entre copias de seguridad y procurad que los discos vayan bien protegidos en el en- 
vío). En fin, por fin podemos contar hoy con la 

Orcos y humanos, etc, etc. famosa vagoneta de ataque Snotling (o algo pa- 
recido) que Oscar diseño para ayudar a los orcos 

Damas y ca balleros, en su batalla virtual contra los humanos. Dispo- 
nemos ya de varios piezas así que pronto podre- 

pasen, vean y mos preparar alguna batallita, aunque si alguien 
se anima a preparar el altar de guerra Imperial o 

| asómbrense. el cañón de salvas, mejor. Enhorabuena por es- 


tas estupendas máquinas, Oscar. 
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El Foro del Lector 


nos 
envía varias esce- 
nas con efectos 
atmosféricos y 
una utilidad para 
generar superfi- 


cies extruidas y 


miembro 
del grupo Njteam nos envía su últi- 
ma creación, una grúa basada en una 
pieza a escala, Puesto que Nasser pi- 
de una Opinión diré que. desde lue- 
go, este trabajo representa un paso 
adelante (sobre todo en complejidad 
de modelado) con respecto al orde- 
nador que enviaste la última vez. Lo 
único que no me ha convencido de- 
masiado ha sido el fondo, que no me 
parece a la altura del modelo. En 
cuanto a los Ipas de 3D Studio que 
pides para el CD-Rom si no se trata 
de versiones shareware o autoriza- 
das, no cuentes con ello. Respecto a 
lo que dices de los cuelgues de 3D 
Studio por falta de memoria, no me 


parece probable que sea éste el moti- 


vo. ¿Qué versión tienes? 


De inexcusable lectura es la interesantísima carta remitida por 
donde explica como empleó el Metareyes 

para construir las Super Cabezas Extraterrestres que podéis ver 
aquí. Estas cabezas fueron creadas por David primero en plastilina 
y luego... pero lo mejor será que leáis su carta en el Foro. David in- 
cluye también una animación que mezcla animales reales con un 
fondo de 3D Studio (y que yo no he conseguido ver bien). Enhora- 


buena por tu original y excelente trabajo. 


de revolución. Tomo nota de tu sugerencia acerca de dedicar un 
artículo al sistema de iluminación de POV. También a mi me 
gustaría que Marcos Fajardo se decidiera a pasar su trabajo a la 
última versión de POV. Es una pena que sus efectos se hayan 


quedado en la versión 2.2. En cuanto a lo que dices de los halos, 


aunque no tengo los ficheros origi- 
nales (ya que fuiste cambiando los 
valores), creo que es posible que el 
problema resida en el escalado del 


halo con respecto al objeto conte- 


* nedor, aunque eso no parece expli- 


car la sombra. Por último, en lo que 
respecta al uso de Lparser, no re- 
cuerdo cómo dar colores individua- 
les (sin trastear en el fuente con un 


editor). Es posible que dentro de po- 


co veamos aquí algunas técnicas para la generación 
de árboles, ya que parece haber bastante gente inte- 
resada en el tema. Y para acabar. no he podido por 
ahora echar un vistazo a tu Editor de Splines. Pero, 
aunque no pretendo desanimarte, sera difícil que tu 
utilidad tenga mucha salida. A fin de cuentas este te- 


ma esta contemplado en Moray y otros programas. 


también ha decidido tomar parte 
en la anunciada batalla virtual entre orcos y humanos y 
contribuye con este magnífica pov-catapulta que pasa a 
formar parte del bando orco. Daniel pide una crítica 
“constructiva” (¡Ja!) de sus imágenes. Bien ¿qué pode- 
mos decir? La catapulta está esplendidamente diseñada y montada. las texturas (a 
pesar de tus temores) quedan perfectamente y no encuentro ningún punto débil 
salvo en la bola de fuego que. por atro lado. no es fácil de hacer. Quizá hubieras 
debido poner una piedra normal. Anótate un 10.5 sobre 10. En cuanto a lo que pre- 


guntas sobre exportación de modelos de Imagine para POV, supongo que habrás 


leído el resto del presente número. 


-Dark infográfica- es otro in- 


fografista claramente inspira- 
do en el ejemplo de Tomwo- 
of y sus mangababes. José María ha creado un modelo femenino 
para 3D Studio al que llama Chunli (pero que no tiene nada que 
ver con el personaje de Street Fighter que pega palizas al autor de 
estas líneas los sabados por la 
mañana). Este modelo. del 
que podéis ver unos ejemplos 
aquí, puede ser recibido por 
todo aquel que decida regis- 
trarse (ved los detalles expli- 
cados por Joée María en los 
ficheros del foro). Buena suer- 
te para ti y para los siguientes 


modelos de la librería Chunli. 
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comentario acerca de lo resultonas que son tus imágenes. De éstas me gustó sobre todo la ciudady también me gustó mucho el androide 
femenino, aunque hubiera preferido verlo de cuerpo entero. Sin embargo, me veo obligado a señalarte que, al no haberme remitido los fi- 
cheros de generación. no puedo asegurar públicamente que las imágenes sean tuyas. Si eres un lector reciente quiza no hayas leído mis rei- 
teradas explicaciones acerca del porqué de todo esto. Quiero aprovechar la ocasión para pedir a todos que enviéis alguna prueba de que las 
escenas son efectivamente vuestras. Así, a partir de ahora: 1) No hace falta que enviéis los archivos de generación completos. Bastará con 
que, al renderizarlos, se creen escenas con elementos significativos de las imágenes enviadas. Estos archivos, en cualquier caso, no serán 
publicados si el autor así lo declara. 2) Si se trata de escenas de 3D Studio, Imagine o de cualquier otro programa de tipo poligonal, se agra- 
decera una pequeña explicación acerca de los modelos o de cualquier otra cosa que pueda permitirnos confiar en la autoría de las obras en- 
viadas. No es preciso que enviéis las mallas si no deseáis verlas publicadas. 3) Si es 
posible, enviad los discos por duplicado. 4) Si me entero de que alguien me “cuela” al- 
guna obra robada seré el primero en denunciar el hecho y poner pasquines hasta en el 
himalaya para que el culpable no escape al escarnio público. 

Cambiando de tema, nadie usa manualmente Smooth Triangle, ya que es una pri- 
mitiva puesta ahí por los desarrolladores de POV para que sea usada por los programas 
de utilidad que convierten mallas de otros programas; para que sus modelos puedan 
generarse en POV, claro, En cuanto a lo de las formas orgánicas, no se trata de una fal- 
ta de conocimientos o de habilidad por tu parte, sino de un campo muy, muy difícil, in- 


cluso empleando los modeladores y las utilidades más poderosas. 


Jorge Martin Cuervo se lleva hoy la medalla a la originalidad puesto que nos envía 


una colección de piezas de Tente diseñadas conjuntamente con POV y 3D Studio. 


Zeni Lallo nos envía desde Sabadell cuatro escenas magníficas. En su 
carta -que Zeni no ha enviado como fichero- este autor declara que 
aún se considera un novato en el uso de POV y que desconoce el fun- 
cionamiento de las estructuras complejas del programa tales como 
Smooth Triangle (¿?) En su carta Zeni solicita una crítica constructi- 
va y pregunta por el grado de calidad de sus trabajos. Finalmente Ze- 
ni pregunta por qué es tan difícil modelar formas orgánicas con POV, 
el robot femenino iba en principio para chica de carne y hueso. 

Bien, vayamos por partes: Amigo Zeni tus escenas son muy buenas. 
sobre todo en el aspecto del modelado, y me han gustado mucho. 


Sin embargo, has omitido el envío de los ficheros de generación sin 


los cuales mi crítica tiene que reducirse necesariamente a un breve 


Con dichas piezas, Jorge ha montado los barcos de ju- 
guete que podemos ver aquí. (;!). Jorge también nos en- 
vía un proyecto de cocina creado con 3D Studio y que ha 
quedado incompleto debido a otro de esos desastres in- 
formáticos. Jorge pide que enviémos opiniones sobre su 
trabajo así que aprovecharé para dar la mía: La idea de la 
colección de piezas Tente me parece muy original y bien 


realizada pero... ¿Se puede construir un castillo con ello? 


